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A  Software  Defined  Radio  (SDR)  allows  a  single  hardware  p  la  form  to  be  reconfigurable  so  that  it  can  accommodate  mul¬ 
tiple  radio  waveforms  and  be  easily  upgraded  with  software  changes.  The  Joint  Tactical  Radio  System  JTRS)  is  the 
Department  of  Defense’s  (DoD)  solution  for  a  family  of  tactical  SDRs  based  on  common  open  standards  and  architectures. 

JTRS  accommodates  legacy  and  new  mobile  ad  hoc  networking  waveforms.  Additionally,  military  Satellite  Communication, 
and  Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  terminals  are  migrating  to  SDRs  to  enable  consolidation  of  multi¬ 
ple  legacy  systems  into  single  multi-band  configurations.  This  article  describes  current  military  SDR  programs,  their  challenges, 
and  the  way  ahead  for  the  DoD. 


Current  communications  systems 
have  evolved  to  meet  service  specif¬ 
ic  and  mission  specific  requirements. 
Specialized  functionality  has  resulted  in 
limitations  in  communicating  from  one 
system  to  another  resulting  in  interoper¬ 
ability  issues.  More  recent  DoD  systems 
such  as  Link-161  have  made  large  strides 
in  providing  more  capable  and  interoper¬ 
able  data  links;  however,  the  DoD  must 
now  evolve  to  acquire  a  family  of  high 
capacity,  interoperable,  networked,  and 
affordable  radio  systems  as  part  of  the 
transport  layer  of  the  Global 
Information  Grid  (GIG). 

The  appeal  of  SDRs  is  the  ability  to 
handle  multiple  radio  communication 
protocols  on  a  single  hardware  platform 
by  means  of  programmable  hardware 
controlled  by  software.  From  a  DoD 
perspective,  the  reprogrammable  radio 
can  store  and  run  multiple  waveforms. 
Rather  than  developing  many  different 
radio  systems  operating  to  different  stan¬ 
dards,  SDRs  enable  the  DoD  to  have  a 
family  of  interoperable  radios  based  on 
common  waveforms,  standards,  and 
interfaces. 

For  the  DoD,  the  impetus  for  SDRs 
is  to  significantly  reduce  the  number  of 
different  radios  and  waveforms  in  the 
inventory.  Hand  in  hand  with  these 
reductions  is  the  elimination  of  propri¬ 
etary  or  unique  implementations,  elimi¬ 
nating  interoperability  issues.  Costs  to 
the  DoD  for  radio  systems  are  also  sig¬ 
nificantly  reduced,  and  SDRs  contribute 
to  net-centricity  by  enabling  newer  high- 
rate,  networked  waveforms. 

DoD  SDR  Programs 

Trying  to  develop  a  reduced  set  of  radios 
and  waveforms  for  the  DoD  generates 
challenges  in  itself  as  the  family  must 
accommodate  numerous  requirements 
from  each  service.  Software  flexibility 
provides  the  ability  for  operation  of 
many  waveforms  on  single  hardware 


platforms;  however,  there  are  still  many 
additional  unique  military  challenges. 
The  radios  must  be  useful  in  air,  sea,  and 
ground  applications  with  different  size, 
weight,  power,  environmental,  and  threat 
needs. 

To  develop  a  family  of  radios  useful 
to  all  services,  the  Joint  Tactical  Radio 
System  (JTRS)  Program  was  initiated  in 
1997.  Initially,  waveforms  and  crypto¬ 
graphic  applications  were  controlled  by 

“The  JPEO  is  developing 
and  implementing  a 
common  infrastructure 
across  all  domains  to 
define  a  host 
environment  that  ensures 
a  waveform  porting 
among  JTR  sets.” 

the  JTRS  Joint  Program  Office,  and 
JTRS  hardware  development  was 
assigned  to  service  leads.  The  DoD 
recently  restructured  the  program  so  that 
all  JTRS  products  would  be  under  the 
control  of  the  Joint  Program  Executive 
Office  JTRS  (JPEO  JTRS).  JTRS  pro¬ 
grams  currently  include  Ground; 
Airborne,  Maritime,  and  Fixed  Site 
(AMF);  and  Network  Enterprise 
Domains  (NED).  The  ground  domain 
includes  ground  vehicular,  Manpack 
radio,  handheld,  and  special  applications. 
The  AMF  domain  includes  standard  air¬ 
borne,  Multifunctional  Information 
Distribution  System  -  JTRS,  and  19-inch 
rack  applications.  The  NED  includes  the 
waveforms,  gateways,  and  common  net¬ 


working  services  products  used  by  the 
other  domains.  Included  within  the 
NED  programs  are  new  networking 
waveforms  based  on  Internet  Protocol 
(IP)  standards  that  allow  interoperability 
and  include  Mobile  Ad-Hoc  Network 
(MANET)  protocols  for  operation  over 
bandwidth  constrained  and  potentially 
intermittent  wireless  links. 

The  JPEO  is  developing  and  imple¬ 
menting  a  common  infrastructure  across 
all  domains  to  define  a  host  environment 
that  ensures  waveform  porting  among 
JTR  sets.  The  hardware  domains  have 
been  partitioned  to  allow  common  core 
hardware  and  software  in  each  domain, 
which  is  then  tailored  with  additional 
modules  to  apply  to  its  unique  applica¬ 
tions.  To  ensure  waveforms  are  portable 
and  perform  as  intended,  they  go 
through  a  rigorous  certification  process 
under  the  auspices  of  the  JPEO. 

The  foundation  for  the  JTRS  family 
of  radios  is  the  Software  Communi¬ 
cations  Architecture  (SCA),  Figure  1  [1]. 
It  is  simultaneously  an  architecture 
framework,  specification,  and  guidance 
document  for  software  defined  radios 
allowing  convenient  reuse,  update,  or 
replacement  of  software.  The  JPEO 
JTRS  currently  has  over  3.5  million 
source  lines  of  SCA  compliant  code  in 
its  Information  Repository  (IR)  [2] 
developed  by  the  JTRS  community. 
When  a  new  JTRS  program  requires 
software,  the  program  developers  down¬ 
load  it  from  the  IR,  which  enhances 
interoperability  of  JTR  sets,  since  all 
instantiations  are  based  upon  the  same 
software. 

To  further  support  waveform  porta¬ 
bility  and  code  reuse,  the  SCA  specifies 
operating  system  Application  Program¬ 
ming  Interfaces  (APIs)  that  must  be  pro¬ 
vided  by  the  JTR  set’s  Real  Time 
Operating  System  (RTOS).  Labeled  the 
Application  Environment  Profile  (AEP) 
in  Figure  1,  the  SCA  specifies  a  subset  of 
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Figure  1:  SCA  Component  Architecture 

the  Portable  Operating  System  Interface 
that  every  JTR  set  must  support  and  to 
which  each  waveform  is  limited.  In  com¬ 
bination  with  the  defined  Common 
Object  Request  Broker  Architecture 
middleware,  the  SCA  guarantees  that 
every  SCA-compliant  object  can  be  exe¬ 
cuted  upon  any  JTR  set. 

Originally,  JTRS  was  envisioned  to 
cover  the  entire  radio  spectrum. 
However,  during  the  JTRS  restructure, 
the  DoD  determined  that  satellite  com¬ 
munications  and  line-of-sight  radios 
operating  in  the  Super  High  Frequency 
(SHF)  and  the  Extremely  High 
Frequency  (EHF)  spectrum  have  a  large 
enough  set  of  distinct  features  and 
requirements  to  keep  them  separate 
from  the  JTRS  Program.  One  of  the 
largest  differences  is  the  high  throughput 
demands  of  some  of  the  SHF  and  EHF 
waveforms.  In  addition  to  JTRS,  the 
DoD  has  continued  with  a  set  of  multi¬ 
band  SHF/EHF  terminal  SDR  pro¬ 
grams  led  by  the  services.  These 
SHF/EHF  programs  invoke  the  JTRS 


SCA;  additional  collaborative  possibili¬ 
ties,  including  a  common  reference 
architecture,  are  being  pursued. 

SHF/EHF  Programs  include  the  fol¬ 
lowing: 

•  Air  Force  Family  of  Advanced 
Beyond  Line-of-Sight  Terminals. 

•  Army  High  Capacity  Communica¬ 
tions  Capability. 

•  Army  Joint  Command,  Control, 
Computers  ISR  (JC4ISR). 

•  Multi-Role  Tactical  Common  Data 
Link  Demonstration  Program. 

•  Navy  Multi-band  Terminal. 

JTRS  Enterprise  Architecture 

JTRS  is  a  family  of  radios  which  spans 
across  multi-channel,  vehicle-mounted 
radios  to  disposable,  unattended  ground 
sensors.  Although  early  expectations 
might  have  been  for  one  software  suite 
that  could  be  installed  into  any  radio,  it  is 
not  practical  to  deploy  radios  with  capa¬ 
bilities  exceeding  their  missions. 
Individual  JTR  sets  are  expected  to  reuse 
as  much  host  environment  software  as 


possible  from  the  JTRS  information 
repository,  but  are  permitted  to  integrate 
unique  implementations  of  devices  and 
services  as  long  as  the  JTRS  APIs  are 
supported.  The  set  provider’s  primary 
responsibility  is  to  meet  mission  require¬ 
ments.  Waveform  software  is  expected  to 
be  largely  consistent  across  all  JTR  sets. 

To  achieve  interoperability  and  soft¬ 
ware  reuse,  the  JTR  set  providers  are 
required  to  provide  set-to-waveform 
interfaces  that  are  consistent  across  the 
JTRS  enterprise  [3].  The  JTR  set  imple¬ 
mentations  of  components  may  be 
unique,  but  the  exposed  interfaces  to  the 
waveforms  are  standardized.  Figure  2 
shows  the  deployment  of  the  JTRS 
infrastructure. 

The  infrastructure  defines  the  host 
environment  for  all  JTRS  software  com¬ 
ponents.  A  software  component  in  an 
unattended  ground  sensor  has  exactly 
the  same  operating  system  functions,  the 
same  middleware  communication,  and 
the  same  hardware  interfaces  as  a  soft¬ 
ware  component  deployed  in  a  multi- 


Figure  2:  Deployment  of  the  JTRS  Infrastructure 
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Figure  3:  Evolution  of  SDRs 

channel  vehicle-mounted  radio. 
Regardless  of  whether  the  software 
component  is  a  general  purpose  proces¬ 
sor,  Digital  Signal  Processor  (DSP),  or 
Field  Programmable  Gate  Array  (FPGA) 
component,  the  JTRS  infrastructure  fur¬ 
ther  defines  a  host  environment  that  is 
consistent  across  the  enterprise. 
Implementations  may  vary  due  to  the 
mission  or  size,  weight,  and  power 
requirements,  but  the  host  environment 
and  the  exposed  radio  services  and  hard¬ 
ware  interfaces  are  the  same. 

JTRS  SCA  and  Enterprise 
Architecture  Future 
Increments 

The  JTRS  infrastructure  of  Figure  2  has 
resulted  in  an  executable  and  sustainable 
deployment  model  for  the  JTRS  family 
of  radios.  The  requirements  for  the  next 
increment  of  JTRS  are  still  in  develop¬ 
ment,  so  it  is  early  to  conjecture  about 
the  feature  set  of  the  next-generation 
JTRS  infrastructure.  Because  the  infor¬ 
mation  repository  will  have  approxi¬ 
mately  four  million  lines  of  source  code 
from  JTRS  Increment  1,  it  is  probable 
that  the  future  infrastructure  must  be 
backward  compatible  with  today’s  infra¬ 
structure. 

As  additional  form  factors  are  devel¬ 
oped,  there  may  be  minor  revisions  to 
the  SCA  to  extend  the  current  architec¬ 
ture.  To  better  support  battery-powered 
missions,  there  may  be  specific  changes 
to  the  RTOS  and  middleware  specifica¬ 
tions.  In  addition,  System  on  Chip  (SOC) 
interconnection  is  becoming  increasingly 
important  and  standardization  may  be 
required  because  FPGAs  have  become 
capable  of  hosting  increased  functionali¬ 
ty  of  the  SDR. 

SDR  Challenges 

Because  of  the  complexity  of  SDRs,  sys¬ 
tems  and  software  engineering  is  more 
important  now  than  for  the  previous  gen¬ 
eration  of  radios.  Developers  in  both  the 
commercial  and  DoD  sectors  must 
ensure  sufficient  training  and  experience 
necessary  for  SDR  development  includ¬ 
ing  engineering  disciplines  of  communi¬ 


cations  systems,  radio  frequency,  digi¬ 
tal/  analog  hardware,  software,  and  digital 
signal  processing.  Complementing  a  need 
for  developer  training  is  the  requirement 
for  improved  development  and  test  tools. 
Recognizing  the  need  and  potential  mar¬ 
ketplace,  several  companies  have 
emerged  specifically  targeting  SDR  devel¬ 
opment  tools.  A  key  item  in  achieving 
waveform  reuse  is  the  use  of  compatible 
tools  with  thoroughly  documented  code. 

An  additional  challenge  for  the  SDR 
developer  is  to  design  the  architecture 
such  that  interfaces  may  be  replaced  with 
a  different  standard  at  a  future  date.  The 

“SDRs  will  be  able  to 
handle  new  networking 
waveforms,  while  also 
being  able  to  operate 
prior  legacy  waveforms 
so  that  interoperability 
can  be  maintained  as 
the  older  waveforms  are 
phased  out.” 


selection  of  a  set  of  open  standards 
among  many  competing  standards  is  also 
a  challenge  for  DoD  in  achieving  more 
reuse  of  hardware  and  software  among 
programs. 

Hardware  innovations  and  improve¬ 
ments  are  required  for  SDRs  to  achieve 
their  full  potential.  Greater  performance 
can  be  achieved  with  improved  analog  to 
digital  (A/D)  and  digital  to  analog  (D/A) 
converters;  reduced  power  parts,  espe¬ 
cially  FPGAs;  wider  bandwidth  and 
more  linear  amplifiers;  and  radio  fre¬ 
quency  (RF)  technology  allowing  wider 
bandwidth  operation.  For  SHF/EHF 
systems,  improvements  are  needed  to 
reduce  the  high  costs  of  the  steerable, 
directional,  antenna  systems. 

A  unique  challenge  for  DoD  is  that 


radio  life  cycles  are  three  to  10  times 
longer  than  commercial  products.  The 
life  cycle  was  less  problematic  with  hard¬ 
ware  defined  radios,  but  SDRs  utilize 
commercial  products  such  as  operating 
systems,  middleware,  and  software  devel¬ 
opment  tools.  DoD  platforms  such  as 
aircraft  carriers,  aircraft,  submarines, 
etc.,  have  very  long  life  cycles.  SDRs  rep¬ 
resent  an  opportunity  to  update  the 
communications  capabilities  in  these 
platforms  for  relatively  low  cost. 

Evolution  of  DoD  SDRs  Into 
the  Future 

SDRs  will  continue  to  play  a  larger  role 
in  allowing  military  users  to  seamlessly 
interoperate  and  provide  the  wireless 
interface  to  the  GIG.  In  addition,  SDRs 
will  help  reduce  the  total  number  of 
radios  in  the  DoD  inventory,  allow  field¬ 
ed  systems  to  be  more  easily  refreshed 
and  upgraded,  and  help  with  the  drive 
towards  a  reduced  number  of  wave¬ 
forms  and  protocols.  SDRs  will  be  able 
to  handle  new  networking  waveforms, 
while  also  being  able  to  operate  prior 
legacy  waveforms  so  that  interoperability 
can  be  maintained  as  the  older  wave¬ 
forms  are  phased  out.  The  evolution  of 
SDRs  is  shown  in  Figure  3. 

Ubiquitous  Connectivity 

The  next  increment  of  SDRs  must  con¬ 
tinue  the  paradigm  shift  from  a  communi¬ 
cations  model  of  disparate,  service-owned 
and  operated  radio  communications  to 
net-centric  warfare  by  unifying  communi¬ 
cations  resources  that  are  shared  across 
cooperating  services.  The  current  incre¬ 
ment  of  JTRS  is  evolving  the  radio  and 
networking  technologies  necessary  to  real¬ 
ize  this  vision.  Net-centric  warfare  inte¬ 
grates  mobile/ tactical  users  via  networked 
IP  and  meets  frontline  demands  for  band¬ 
width.  The  next  generation  transport 
architecture  will  include  routers  and  trans¬ 
lation  services  to  enable  meaningful  and 
seamless  connectivity  between  multiple, 
diverse  tactical  and  theater  networks  and 
satellite  resources.  SDRs  must  incorporate 
frequency  reuse  mechanisms  to  maximize 
use  of  available  spectrum. 
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Spectrally  Aware 

Frequency  bandwidth  is  required  to  sup¬ 
ply  the  warfighter  with  the  information 
needed  for  tomorrow’s  battlefield.  Unfor¬ 
tunately  there  is  a  dearth  of  unassigned 
frequency  spectrum  and  without  simulta¬ 
neous  regulatory  and  technology  break¬ 
throughs,  radio  spectrum  will  become  a 
limiting  resource  for  the  DoD.  A  poten¬ 
tial  reuse  mechanism  is  a  spectrally  aware 
radio  that  is  trusted  by  regulatory  agen¬ 
cies  to  monitor  the  frequency  spectrum 
and  only  transmit  in  unused  frequencies. 

Reduce  Costs 

The  JTRS  program  has  consolidated  mul¬ 
tiple  radio  domains  under  a  single  pro¬ 
gram  executive  office.  Through  the  use 
of  a  common  infrastructure,  the  JTRS 
JPEO  is  maximizing  reuse  of  products 
through  its  enterprise  and  correspond¬ 
ingly  reducing  development  and  procure¬ 
ment  costs.  Additionally,  a  core  set  of 
interoperable  networking  waveforms  is 
being  developed.  Currently,  the  DoD  is 
continuing  with  individually  managed 
service  multi-band  SHF/EHF  programs; 
however,  future  collaborative  possibilities 
are  being  examined.  Reuse  of  the  SCA 
and  some  of  the  JTRS  enterprise  archi¬ 
tecture  is  anticipated,  with  additions  as 
needed  to  establish  an  SHF/EHF  refer¬ 
ence  architecture. 

Waveform  Coverage  for  All 
Missions 

Communications  for  DoD  missions  vary 
from  dismounted  soldiers  in  the  canyons 
of  Afghanistan,  supersonic  aircraft,  unat¬ 
tended  ground  sensors  in  the  tropics,  to 
conventional  office  environments. 
Although  one  waveform  for  all  communi¬ 
cations  would  be  desirable,  it  is  as  imprac¬ 
tical  as  expecting  that  all  DoD  transporta¬ 
tion  needs  can  be  served  with  a  single 
vehicle.  The  next  increment  of  SDRs  will 
provide  coverage  of  all  DoD  communica¬ 
tion  needs  with  fewer  waveforms. 

Outlook 

The  development  and  use  of  SDRs  is  a 
key  enabler  for  DoD  in  achieving  a  fami¬ 
ly  of  interoperable  radios  based  on  com¬ 
mon  waveforms,  standards,  and  inter¬ 
faces,  with  enhanced  portability  and 
reusability.  While  there  have  been  signifi¬ 
cant  developmental  challenges,  the  DoD 
SDR  programs  have  made  good 
progress,  with  prototypes  available  and 
being  tested  in  the  field  for  several  JTRS 
and  SHF/EHF  programs.  As  users  gain 
familiarity  and  experience  with  these 
radios,  their  transformational  communi¬ 


cations  capabilities  will  become  evident. 
The  reprogrammable  SDR  will  allow  fur¬ 
ther  evolution  to  additional  advanced 
capabilities  building  upon  the  current 
programs.^ 
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Note 

1.  Link- 16  is  a  secure  near  real-time  situ¬ 
ational  awareness  and  command/ con¬ 
trol  data  link  used  on  the  Joint  Tactical 
Information  Distribution  System  and 
Multifunctional  Information  Distribu¬ 
tion  System  Terminals  of  the  United 
States  and  North  Atlantic  Treaty 
Organization  allies. 
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